COMMENT ⊗   VALID 00018 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00003 00002	@Make[Report]
C00011 00003	@BEGIN{Example}
C00015 00004	@Chapter{ABSTRACT}
C00017 00005	@Chapter[Introduction]
C00020 00006	@Chapter[What is an analogy?]
C00030 00007	@Chapter[Simple Analogy Examples]
C00037 00008	@Section[Case II - Informal]
C00041 00009	@Comment{ Fred/Jill cases }
C00044 00010	@Comment{ Intro to Brand X(s) }
C00045 00011	@Chapter[Part to Part Mapping]
C00048 00012	@Chapter[Symbol to Symbol Mapping]
C00050 00013	@Chapter[Common Class]
C00051 00014	@Chapter[Common Theory]
C00052 00015	@Chapter[Answer: Common theory + Mappings]
C00053 00016	IX. Notion of mapping sentence to sentence
C00054 00017	@Chapter[Acknowledgements]
C00055 00018	@BEGIN[Comment]
C00056 ENDMK
C⊗;
@Make[Report]
@Device[DOVER]
@LIBRARYFILE<SPECIALCHARACTERS>

@Case{Device,	FILE "@Style(Endnotes)",
		PAGEDFILE "@Style(Endnotes)"}

@Modify[Verbatim, Break Before]
@Modify[Description, Spread 0, Spacing 1.3, LeftMargin +10, Indent -10]
@Modify[Quotation, Indent 0]
@Modify[Itemize, Referenced <@#>]
@Modify[Enumerate, Referenced <@#@;#@:.@1@,@#.@a@,@#.@i>]
@Modify[Appendix, Numbered <@A.>, Referenced <@A>]
@Style[References=STD Alphabetic]
@DEFINE[Aside=NoteStyle, LeftMargin -16, Indent 0]
@DEFINE[SubAside=Quotation,Font SmallBodyFont,FaceCode I,Spacing 1,Spread 0.5]
@DEFINE[Subsubsection,Use HdX,Font TitleFont3,FaceCode I,Above .3inch,Centered]
@DEFINE[ENUM0=ENUMERATE, NumberFrom 0, SPREAD=0, Above=0.3 line, Below=0.1 line]
@DEFINE[ENUM1=ENUMERATE, SPREAD=0.1, Spacing=1, Above=0.3 line, Below=0.1 line]
@TEXTFORM[BEGENUM1 = 
	"@BEGIN<ENUMERATE, SPREAD=0.1, Spacing=1, Above=0.3 line, Below=0.1 line>"]
@TEXTFORM[ENDENUM1 = 
	"@END<ENUMERATE>"]
@DEFINE[ITEM1=Itemize, Spread=0.1, Spacing=1, Above=0.3 line, Below=0.1 line]
@DEFINE[DESC1=Description, Spread=0, Spacing=1, Above=0.3 line, Below=0.1 line]
@DEFINE[TEXT1 = TEXT, USE NoteStyle]

@EQUATE[YY=R]

@Counter[EquationCounter, Numbered <(Facts @1)>, Referenced <(Facts @1)>,
IncrementedBy tag, INIT 0]

@Comment{ Now to keep from Breaking in front of chapters. }
@DEFINE(HdChap,Use HD1,PageBreak Off,Above .6inch)
@Counter(Chapter,TitleEnv HdChap,
	ContentsEnv tc1,Numbered [@1.],IncrementedBy Use,Referenced [@1],Announced) 
@Comment{How annoying!   Without this, the section numbers don't get reset!
	Note this is exactly what's in REPORT.MAK[scr,sys]. }
@Counter(Section,Within Chapter,TitleEnv HD2,ContentsEnv tc2,
	  Numbered [@#@:.@1],Referenced [@#@:.@1],IncrementedBy Use,Announced)

@Use(Bibliography =  "GENL.BIB[RDG,DBL]")
@Use(Bibliography =  "REPN.BIB[RDG,DBL]")
@Use(Bibliography = "META4.BIB[RDG,DBL]")

@Unnumbered[References]
@Bibliography
@BEGIN{Example}
What's in an Analogy
(6/VIII/82)
				 Outline:

0. Abstract

I. Introduction 
  A. Purpose of paper
  B. Overview of paper

II. What is an analogy 
  A. Takes two analogues (not familiar)
  B. Both Similarity & Proportional (unified by Rel(A B))

III. Examples
  A. Group theory (formal)
  B. Fred/Jill sentences - for input language
	[informal]

IV. Overview of paper
  A. For each View of Analogy
	[See below; finish with our 5-ary case]
    i. Description of this case
    ii. Case where works well
    iii. Pro/Con of this case
    iv. Case where this fails
  B. Problems with our case
  C. Related issues - defn of instance, reformulation
	what of ___

V. Mapping
  A. Part to Part
	Pro - simple, usually used, fast, just matching of given description
	Con - can't find "obvious analogies" based on rel'ns (see B.)
  B. Symbol to Symbol - subparts and relations
	Pro - solves many problems
	Con - requires given rep (can't reformulate)
	   no "common features" -- for learning, speed ups, or inventory of analogues, ...

VI. Common Class
   Each analogue is an instance of this class.
   Need to define "instance" -- not simple notion of set membership
	Pro - simple, straightforward (especially for inclusion), first order (non-meta)
	Con - Hard to state what is excluded,
		what are instantiations?  Subparts?  How to establish mapping?

VII. Common theory
   Each analogue satisfies this theory.
	Pro - in meta-theory, easy to indicate inclusions/exclusions
	Con - what are mappings?
		especially hard when using different languages

VIII. Answer: Common theory + Mappings
  Solves instantiation issue, and hence leads to mappings (see IV)
  Symbol-Symbol doesn't work -- needs sentence to sentence
	Here want to have some notion of consistency
	Standard decomposition not adequate

IX. Notion of mapping sentence to sentence

X. Desired propoperties of analogy

@END{Example}
@Chapter{ABSTRACT}

It is quite tempting to view an analogy as a mapping between
the parts of the two analogues.
Unfortunately there are several limitations inherent in this approach.
  After defining our terms, 
  (e.g. the class of analogies to be discussed,)
This paper will discuss these deficiencies,
(in a well-defined context)
and then explore the 
{pros and cons} | {advantages and problems}
associated with several refinements of this characterization
  of analogy.
This survey culminates with a definition which seems adequate
to handle all common uses of analogy.
The conclusion discusses several of the remaining issues which
need to be resolved before this definition can be used.
(The focus is on its use by a running "Analogizing" program.)

@Chapter[Introduction]
@LABEL{Intro}

The purpose of this paper is to present a well-defined, powerful definition
of the (too often used) term, analogy.
Chapter @Ref(QuickDefn) provides a coarse "naive" description of analogy;
delimiting the types of situations which (for our purposes) do, or do not,
qualify as an analogy.
Chapter @Ref[Examples] then presents a small body of quick, "local" examples;
whose breadth is (or at least seems) sufficient to span
the significant different cases,
covering both formal and informal senses.

After this we present an army of straw men --
each a definition of analogy with which certain classes of analogy problems
can be readily encoded, but which is, in some way, too limiting.
Each of these descriptions is systematically proposed and evaluated,
based on its assets and faults.
This culminates with the "correct" view of analogy, promised above.

The balance of this paper looks in depth at this particular definition of analogy;
commenting first on its advantanges and generality, and then discussing some of
its problems -- especially those which make it difficult to actually implement.

<<here - write this after rest of paper>>
explain why we feel it "works" -- that is, can be used to handle a wide
range of (perhaps all?) analogy problems/situations.  The conclusion
will discuss some of the remaining issues -- points, both minor and major,
which must be resolved before we can claim to have painted a coherent picture
of analogy, sufficiently complete to actually implement.
----

?? Various appendices will cover additional things -- such as expected properties
of analogies (to be exhibited by any model/implementation...) and ...
@Chapter[What is an analogy?]
@Label{QuickDefn}

To ground this discussion on analogy, it is essential to specify 
(at least superficially)
just what we will mean (and, importantly, do not mean) by the term analogy.
For our purposes, an analogy is a relation 
which connects a pair of objects/events/things/...,
and involves other (to be specified) parameters.
Informally, we think of an analogy as indicating the @i{commonality} of the
two analogues.
{Our overall quest} | {The purpose of this paper}
is a more exact specification of this relation
-- asking, in particular, what those other arguments to this
Analogy relation are.

Some comments on the types of analogies we will consider:
First, it is NOT limited to just similarity analogies;
it can readily handle proportional analogies as well.  
The trick here is to convert the proportional analogy,
@i[A:B :: C:D], into a similarity analogy, whose analogues are the terms
@i[REL(A B)] and @i[REL(C D)],
where
@i[REL(@g<a> @g<b>)] denotes a relation which holds between
@g<a> and @g<b>.
We can now talk about this pair of relations, as we could any other object.
(Bravo for 2nd order languages.)

However, as we are dealing with @i{pairs} of analogues,
we are NOT considering familiar relations, which deal with n-tuples of analogues
or their features.
(This class includes cases like "all mammals are similar", and
"one can put the jaw bones of all mammals into correspondence".)
We do, however, claim that a relatively straightforward modificiation to
our approach will enable us to deal with such cases.

Imagine that two analogues are enterred into an analogizing program.
What type of thing should then be "returned"?
Or, viewing it less procedurally and more relation-ally,
what are the other arguments to the "ANALOGY relation"?
For example, the "mappists" would claim that ANALOGY takes three arguments --
@i{viz.}, the two analogues and the mapping function which
carries the parts of one analogue into the other.
The goal of this paper is a concise answer to this 
"What else is required to specify an analogy?" question.
(See Note @Ref[Gen-Use].)
@Note{@Label[Gen-Use]
A side comment, addressed to those "procedural-ists" who regard an analogy
as a process which takes some inputs and returns some output.
It is very tempting to split the types of analogizing tasks into two partitions --
those which generate/specify an analogy, 
(@i{e.g.}, those programs which generate the desired mapping,)
and those which use or understand the analogy -- for example, those programs
which use the given analogy (perhaps the mapping)
to further specify some property of one (or both) of the analogues.
[Extreme examples: "How is learning at CalTech like sipping water from a fire hose?"
is clearly in the first camp.  The goal is to specify that feature which is common
to both "learning at CalTech" and "sipping water from a fire hose" analogues --
perhaps that, in both cases, a vast amount of material is being forced out,
at a flowrate far beyond the capability of the student/drinker, who is trying
to somehow absorb it.
On the other hand, "Electricity is like Water flow in that both involve the
movement of some material through some specified course" fits nicely into
the second class.  Here the analogy seems well defined; the challenge is to
determine new properties from the Electricity analogue, based on both
facts known about Water Flow, and about the well-specified connection --
that both involve movement of something along a course.

We will see later that this distinction between analogy-specification
and analogy-use is usually fuzzy; if not altogether meaningless.  
In @Cite[WhatAnalogyLike] I conjecture that 
both analogy generation and analogy use/understanding
should both come under heading of analogy refinement.
End of digression.}

By listing various examples of analogy statement,
the next chapter will help to further specify our usage of
{the term}
analogy.
Each of these problem statements refers
to a legal analogical connection which joins a pair of analogues.

@Chapter[Simple Analogy Examples]
@Label{Examples}

This chapter will present a list of "analogy comprehension tasks" --
problem statements which each imply some connection between the pair of analogues.
We feel any adequate Analogizing program should be able to "understand"
any of these -- that is, be able to use the connection
to conjecture some new assertions about one or both of the analogues.

We will consider a wide spectrum of cases -- ranging from very precise and formal,
based on "deep underlying similarities" through relatively shallow and informal
description.
These will be coarsely divided into two broad@Foot{and overlaping}
classes of examples -- labelled formal versus informal.
Each case will be followed with a quick and informal statement of what this
analogy @i{really} means.

@Section[Case I - Formal]

@Center[@B<Totally Specified Analogues, Precise Analogy>]

The integers, under addition, with the zero element 0, are like
the rationals, under multiplication, with the zero element 1,
(in that each structure is an instance of a group).
Symbolically
@BEGIN[Example]
	< @z(Z)@i{,+,0} > @z{=} < @z(Q)@i{,*,1} >
@END[Example]

What does this mean? 
As an instantiation of a group, each structure satisfies the following axioms:
(In fact, we could even should that each is an infinite, (of cardinality @g(w),)
Abelian group -- but that digression is not important here.)

@BEGIN[Example]
Set( Univ(G) )

Zero(G) ε Univ(G)

BinaryOperator( Oper(G) )

Associative( Oper(G) )
  [i.e. ∀ x,y,z ε Univ(G). [(x Oper(G) y) Oper(G) z] = [x Oper(G) (y Oper(G) z)] ]

Identity( Zero(G), Oper(G), Univ(G) )
  [i.e. ∀x. x ε Univ(G) => (x Oper(G) Zero(G) ) = x. ]
@END[EXAMPLE]

where @i[Univ(x)], @i[Oper(x)] and @i[Zero(x)] are unary (skolem) functions
mapping a structure into it's parts;
extracting the first, second and third elements of a triplet, respectively.

This case is, of course, a gross simplification of any real world situation,
in (at least) three ways, all of which will be addressed below.
First, notice that we were already given both structures,
and thereby told, explicitly, both which aspects of @z(Z) to consider,
and how to consider these facets.
In addition, we have been explicitly given the theory
which both of these structures satisfy -- group theory.

@Center[@B<Partially Specified Analogues, Precise Analogy>]

Imagine, instead, being only told that the general structure, @b[INTEGERS],
was similar to the structure @B[RATIONALS],
in that each was an instance of a group.
(The general structure, @b[INTEGERS]
consists of both the obvious universe of elements,
and the wide range of relations pertanent to these members --
including the functions @i{+}, @i{*}, @i{Succ}, ...
relations like @i{>} and @i{Divides}, and constants like @i{0} and @i{1}.
Similarly the structure @B[RATIONALS],
includes several of its operations and constants as well as universe of members.)
Here the task would involve specifying which things correspond to the 
group things -- universe, operation and zero element.
Hence the correspondences could be
@BEGIN[EXAMPLE]
	< @z(Z)@i{,+,0} > @z{=} < @z(Q)@i{,*,1} >
@END[EXAMPLE]
(as it was before,) or
@BEGIN[EXAMPLE]
	< @z(Z)@i{,+,0} > @z{=} < @z(Q)@i{,+,0} >,
@END[EXAMPLE]
or even
@BEGIN[EXAMPLE]
	< @z(Z)@-{7}@i{,*@-{7},1@-{7}} > @z{=} < @z(Q)@i{,+,0} >,
@END[EXAMPLE]
(that is, the integers mod 7, under multiplication).

@Center[@B<Partially Specified Analogues, No Analogy Given>]

Now suppose we were only told that these structures are similar, but not how --
@i{i.e.}, we were not given that each should be consider as a group.
Perhaps we should consider both as rings, or lattices, or ...  
There are arbitrarily many connections one might make -- both those deriving
from some mathematical structure, and otherwise.
(consider that "consecutive subway stops in NYC" example).

@Section[Case II - Informal]

In all of these cases, we were dealing with artifical objects;
and, in the first two cases, the desired commonality was equally man-made.
The third loosening occurs when the analogues refer to natural,
rather than artificial, objects.
With artificial objects, (such as integers,)
we potentially have access to every pertanent fact@Foot<
This is not quite true -- there are various "meta-level" facts
about the integers which are not covered by the standard body of defining
facts.  For example, who first "discovered" them, or the contents of some early
theories about them, @i{etc.}.>,
(Godel's Incompleteness Proof notwithstanding).
When talking about natural objects, like Fred or democracy, however,
we are forced to deal with only an abstraction of the analogues --
that is, all we have is a partial description of the object.
Note @Ref[NeedReform] discusses why this observations leads to
the need for reformulation.

@Note{
@Label[NeedReform]
Analogy is (or should be) a "semantic relation",
which deal with a pair of objects, not only with their descriptions.
Given our total knowledge of integers, this was not much of a limitation --
as we could, (in theory if not in practice) store all relevant facts about
the integers.
We do not have this liberty when dealing with real world objects.
Here the given description of the object may not
explicate (or worse, not even include) the features
which should be in correspondence, for this analogy.
This problem points to the necessity of reformulation for
any sophisticated analogizing program -- that is, the program must be
able to find a different representation for (one or both of) the analogues;
in which the desired commonality is expressed.}

Enough overview.
Below we consider what natural sounding ways of suggesting an analogy.
Each consitutes a description for constraining how these two things can
be analogous.
In many cases, these would not need to be stated explicitly;
this additional information can often be understood implicitly.
The descriptions below can also be used to (partially) define the analogy --
that is, they can indicate how the analogues map into one another.
(Once again refer to Note @Ref[Gen-Use].)

@Comment{ Fred/Jill cases }
Fred is [just] like Jill
@BEGIN(ITEM1)
@ux<in that both are> lawyers.@*
Or: @ux<as both are>, @ux<regarding both to be>, ...@*
@i{I.e.}: both are in the same category or class; and this comparison should
be based on this perspective.

@ux<in terms of> profession.@*
Or: "<Adjective>ily, A is like B", as in "Cognitively, people are like computers."@*
@i{I.e.}: both are in the same category, based on the <Adjective> perspective.

@ux<except that> Jill is female.@*
Or: @ux<were it not that>, @ux<disregarding the fact that>, ... @*
@i{I.e.}: Some implicit, unstated slot [here gender] has a different value.

@ux<ignoring> gender.@*
Or: @ux<excluding>, @ux<disregarding>, ... @*
@i{I.e.}: The value of their respective X slots [here gender] are different.

@ux<considering only their> height.@*
Or: @ux<based only on>, @ux<considering just>, 
@ux<where> X @ux<are the most salient attributes.>@*
@i{I.e.}: The value of their respective X slots [here height] are the same (or similar).

@ux<after substituting> CalTech @ux<for> Stanford.@*
Or: @ux<except in> X @ux<context rather than> Y, 
@ux<but deals with> X @ux<rather than> Y, ...@*
@i{I.e.}: There is a strong (@i{i.e.g.}, causal) reality to the 
proportional metaphor@*
@w(    )Fred:Jill :: CalTech : Stanford@*
There is some relation joining Fred to CalTech holds for Jill and Stanford.

@ux(as) Prince Charming @ux(is to) Cinderella.@*
Or: @ux(a la) Prince Charming @ux(with respect to) Cinderella, ...  @*
@i{I.e.}: (At least) one of the relations joining Prince Charming to Cinderella
links Fred to Jill. Perhaps "loves enough to search for"?
(This is much like the case above.)

@END(ITEM1)
@Comment{ Intro to Brand X(s) }
Each of the next several chapters will present a particular view of analogy.
Based on these examples, we will
indicate the strengths and weaknesses of each approach.

@Chapter[Part to Part Mapping]
@Label[P-P]

This is the most common approach to analogy --
@i{A} and @i{B} are similar whenever their parts (or some relevant subset
of them) can be shown to correspond.
(@Cite(?), @Cite(Winston)...)
In this approach it is easy to see how Fred and Jill are similar in several of
the cases.
Claiming they both are lawyers is tantamount to noting that
the value of their respective Profession slots agree -- i.e.
both have the value "Lawyer".
Saying that they share the same profession is even more obvious.

The values found need not be equal -- often similarity is sufficient.
(Of course this does lead a recursion...)
For example, Fred and Jill might be considered similar
because the respective ancestry was similar --
@BEGIN[EXAMPLE]
	Fred:AncestryFrom = Romania
	Jill:AncestryFrom = Hungary.
@END[EXAMPLE]
Now we have to show that Romania and Hungary are similar.

This carries over nicely to the formal case, in some situations.
For example, the operation slot ...
<<here>>

The approach has many
(quite seductive)
advantages.  
First it is quite fast -- requiring only a relatively simple and
straightforward matcher to work.
Its limitations are, unfortunately, extensive as well.

We will discuss a body of limitations associated with this mapping notion
of analogy after the next chapter.  Those apply to this case as well
as that next one.  Here is a list of problems

can't find "obvious analogies" based on rel'ns 

@Chapter[Symbol to Symbol Mapping]
@Label[S-S]

This extends the part to part mapping to consider the mapping of arbitrary
relations -- not just those values of slots.
(I.e. the slots themselves may well be changed, or, when being PCer, relations.
Needs 2nd order system, of course, to do anything interesting.)

  B. Symbol to Symbol - subparts and relations
	Pro - solves many problems
Con
   no "common features" -- for learning, speed ups, or inventory of analogues, ...
[need to indicate definitional vs assertional -- but this could be handled
with proper meta-level]

Very tied to the representation -- addressed by Reformulation
No commonality ever discovered -- how to build "learning" system?
Inventory of commonalities unusable.

@Chapter[Common Class]
@Label[CC]

This approach is rather different from the previous two.
Here we consider each analogue to be an instance of some class (where
we may need to first define this class before dealing with it -- that is,
it need not be pre-defined.)

E.g. ...
   Need to define "instance" -- not simple notion of set membership
	Pro - simple, straightforward (especially for inclusion), first order (non-meta)
	Con - Hard to state what is excluded,
		what are instantiations?  Subparts?  How to establish mapping?

@Chapter[Common Theory]
@Label[CT]

This approach is quite similar to the prior Common Class case.
Here, instead of satisfying a unary predicate, similarity is determined
by satisfying a common theory.

	Pro - in meta-theory, easy to indicate inclusions/exclusions
	Con - what are mappings?
		especially hard when using different languages

@Chapter[Answer: Common theory + Mappings]
  Solves instantiation issue, and hence leads to mappings (see Chapter @Ref[P-P].)
  Symbol-Symbol doesn't work -- needs sentence to sentence
	Here want to have some notion of consistency
	Standard decomposition not adequate

IX. Notion of mapping sentence to sentence

X. Desired propoperties of analogy

@Chapter[Acknowledgements]

Prominently Prof Micheal Genesereth;
also my advisor Prof Douglas Lenat.
Thanks to Prof Lindley Darden,
and useful comments from
Tom Dietterich,
Patricia Schooley,
and Steve Tappel.
@BEGIN[Comment]
	Outtakes

Thus motivated, we conclude with the view that the analogy relation has
five terms --
in addition to the pair of analogues themselves,
(or more precisely, a pair of descriptions of those objects,)
this definitation includes a common theory, (which both analogues "satisfy"),
and a pair of mappings, which each map sentences from that common theory to each
analogue theory.

Dimensions --
	"Formal"ness of the analogues [1 or 2]
	Pre-existence of (common) theory

Hence the underlying, unifying commonality may or may not be obvious
within a particular description.

@ENDXπomment]